Record delisted pools in a dedicated table instead of using a field in
the `pool_registrations` table.

In the updated schema, a pool is delisted if (and only if) there is a
single row containing that pool's id in the `delisted_pools` table.

This solution has several advantages:

  1.  We only need a single database row to record that a pool is delisted.

  2.  We no longer need to carefully to ensure that all registration records
      for a particular pool have the same delisted status. A pool is either
      delisted or not delisted: the schema rules out all intermediate states.

  3.  Pools automatically remain delisted when rollbacks occur or when new
      certificates are published, with no extra effort.

  4.  The `putPoolRegistration` function no longer needs to read the
      most-recently-written registration entry before adding a new entry.

  5.  Each row in the `pool_registrations` table is now just an immutable
      record of a registration certificate.

  6.  The `PoolFlag` type is no longer necessary.

In response to review feedback:

#2277 (comment)

We must replace the set of delisted pools, rather than augmenting it.

In response to review feedback:

#2277 (comment)

This operation completely replaces the set of delisted pools, rather
than augmenting it. Therefore, the name `delistPools` is slightly
misleading, as it gives the impression that the existing set will be
augmented, which is no longer true.

In response to review feedback:

#2277 (comment)

In particular, we check that 'putDelistedPools' completely overwrites
the existing set every time.

In response to review feedback:

#2277 (comment)

This test no longer makes sense, as delisted pools are no longer stored
in the `pool_registration` table.

In response to review feedback:

#2277 (comment)

In response to review feedback:

#2277 (comment)

  It was a bit awkward to have two completely distinct endpoints for
  this with different paths, whereas they related to exactly the same
  thing. This commit makes the API a bit more consistent by wrapping the
  `gcPoolStatus` inside a `maintenance action` object. So that, the API
  now offers two dual endpoints:

  - post maintenance action
  - get maintenance action

  There's only one maintenance action available at this stage.